Add clickable metadata support to embedded Victory bar charts#96065
Add clickable metadata support to embedded Victory bar charts#96065inimaga wants to merge 25 commits into
Conversation
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
…ded-Victory-bar-charts
…tadata-support-to-embedded-Victory-bar-charts # Conflicts: # src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/context/VictoryChartContext.tsx # src/components/HTMLEngineProvider/HTMLRenderers/VictoryChartRenderer/parsers/processVictoryChartTree.ts
|
@hoangzinh Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
|
If this requires C+ review, I'll be reviewing this as part of project. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c467b0a5c
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
trjExpensify
left a comment
There was a problem hiding this comment.
What's up with the axis here? On the spend page the values are dynamic based on the data set. This looks like it puts all of the bars below the first data point on the axis?
For the data on hover, why aren't we showing the same data as the Spend page?
CC: @Expensify/design @luacmartins
|
Yeah agree, I would think the y axis would use smaller amounts so the bars would be taller? That feels odd for sure. |
The current instructions adjust the axis dynamically, but they set a $500 minimum. So that's why for small amounts we show it like that. I'm not sure why we have the minimum though, we can probably remove that. |
Both flagged issues have now been fixed. It did need a backend change though, so this PR is on hold till Web-E#54677 gets deployed. Issue.-.54677.mp4 |
Just on these in-line charts? 🤔 |
|
@trjExpensify Yes. Not sure why. |
|
Weird. The spend page always starts the bottom line of the y-axis on $0 and then the increments are dynamic based on the data set. |
|
@hoangzinh / @situchan Would either of you be able to review this today? |
|
🚧 inimaga has triggered a test Expensify/App build. You can view the workflow run here. |
|
🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
|
It appears to be part of a project that @situchan is working on. |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari |
|
@situchan How is the review coming along here? Carlos is going out of office today and I'ld like him to take a look before he leaves. |
|
Tooltip looks good but it navigates to the wrong (NOT corresponding) Search results. Screen.Recording.2026-07-23.at.3.27.07.PM.movExample: Correct one: (date should not be wrapped with "") |
| })); | ||
|
|
||
| return ( | ||
| <GestureDetector gesture={customGestures}> |
There was a problem hiding this comment.
There is no interactiveBars.length > 0 guard.
Should we mount GestureDetector/interactive path only when there is at least one interactive bar?
Otherwise render VictoryChartCartesian bare as before.
This avoids running the whole hit-test/flag machinery on hover for charts that can never be interactive.
Affected: horizontal bar charts (isHorizontal → barSeriesConfig = {} → interactiveBars = []), line-type cartesian charts, and vertical bar charts without metadata (i.e. every chart that predates this feature).
What breaks: customGestures = Gesture.Race(Hover, Tap). The Tap gesture activates on every tap and, on native, can consume/delay taps that previously propagated to the parent (message press, attachment open, "mark as read"). The tap resolves findClosestPoint([], x) → -1 and does nothing, so the tap is swallowed silently.
This is the classic "tapping the chart used to do X, now it does nothing" regression.
| const syncBarPositions = (renderArgs: CartesianChartRenderArg<CartesianChartData, YKey>) => { | ||
| const {points, chartBounds, yScale} = renderArgs; | ||
| const xs: number[] = []; | ||
| const ys: number[] = []; | ||
| const widths: number[] = []; | ||
| const searchQueryFlags: number[] = []; | ||
|
|
||
| for (const bar of interactiveBars) { | ||
| const point = points[bar.yKey]?.find((candidate) => candidate.xValue === bar.xValue); | ||
| if (!point) { | ||
| continue; | ||
| } | ||
|
|
||
| const seriesPointCount = points[bar.yKey]?.length ?? 0; | ||
| const geometry = getVictoryBarInteractionGeometry(point, chartBounds, seriesPointCount, barSeriesConfig[bar.yKey]); | ||
| if (!geometry) { | ||
| continue; | ||
| } | ||
|
|
||
| xs.push(geometry.x); | ||
| ys.push(geometry.y); | ||
| widths.push(geometry.width); | ||
| searchQueryFlags.push(bar.searchQuery ? 1 : 0); | ||
| } | ||
|
|
||
| setPointPositions(xs, ys); |
There was a problem hiding this comment.
Index-alignment coupling between interactiveBars and synced position arrays
matchedIndex is used to index both the UI-thread position arrays (pointOX/pointOY/pointWidth/hasSearchQuery) and the JS-thread interactiveBars array:
- Tooltip:
activeBar = interactiveBars.at(activeBarIndex) - Navigation:
interactiveBars.at(index)?.searchQuery
But syncBarPositions builds those position arrays by iterating interactiveBars and continue-ing when !point or !geometry. If any interactive bar is skipped, every subsequent index in the position arrays no longer corresponds to the same interactiveBars entry — so a hover/tap would show/navigate to the wrong bar's metadata.
In practice the arrays stay aligned because interactiveBars is filtered to typeof row[yKey] === 'number' and points should exist, so a skip is unlikely — but this is a fragile invariant maintained by two separate loops.
Consider either (a) building both arrays in one pass, or (b) pushing a sentinel/null on skip so indices never shift, or (c) storing an explicit barIndex in the synced data rather than relying on positional correspondence.
At minimum, a comment documenting the required alignment would help.
|
Reviewed the changes — overall a well-structured PR. The metadata plumbing (parser → One correctness concern worth addressing, plus a minor note. 🟡 The two index spaces can silently desync (wrong tooltip / wrong navigation)
for (const bar of interactiveBars) {
const point = points[bar.yKey]?.find((candidate) => candidate.xValue === bar.xValue);
if (!point) { continue; } // <-- skip
...
if (!geometry) { continue; } // <-- skip
xs.push(...); ys.push(...); widths.push(...); searchQueryFlags.push(...);
}Those arrays define the index space that But
If even one bar is skipped in Suggested fix: keep a single source of truth. Either push the bar's original index (or the Minor
Nice touches: the negative-bar baseline hit-testing ( |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7e35367fef
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| config[getYKey(node)] = {barWidth: parseAttributeAsNumber(node.attributes.barwidth)}; | ||
| return; | ||
| } | ||
| if (node.tagName === 'victorygroup' && !('horizontal' in node.attributes)) { |
There was a problem hiding this comment.
Treat horizontal="false" groups as vertical
When a generated chart serializes a vertical group as <victorygroup horizontal="false">, this presence check drops every child bar from barSeriesConfig, so buildInteractiveBars() never creates targets even though this renderer still renders the group vertically from the chart-level isHorizontal value (the chart parser also treats horizontal="false" as false). As a result grouped bars in that explicit-false form get no tooltip or Search navigation; check the attribute value rather than only its presence.
Useful? React with 👍 / 👎.
|
I checked the logs for this repro. The malformed query was already present in the generated chart metadata. At The frontend then navigated with that metadata. At Its So I am fixing the App-side interaction issues here, but the per-bar chart metadata should be fixed separately in the backend/AgentZero path to emit: instead of: |

Held on:
https://github.com/Expensify/Web-Expensify/pull/54516https://github.com/Expensify/Web-Expensify/pull/54677Explanation of Change
This PR adds per-point metadata parsing for embedded Victory chart data, preserving
labelandsearchQueryfields and carrying them through the Victory chart renderer context.Vertical embedded bar charts should now show web hover tooltips from that metadata and navigate to Search when a bar has a
searchQuery.Fixed Issues
$ #92149
PROPOSAL: N/A
Tests
Automated Tests
Covered by added automated tests
Manual Test
Pre-requisite (Skip to Test Steps if testing in Staging/Prod):
Test Steps:
Issue.92149.mp4
Offline tests
QA Steps
Same as manual test steps above
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari